Many programs are currently implemented in object-oriented programming languages, such as the C++ programming language. The display icons that represent data or resources are typically representations of data structures called objects, which encapsulate attributes and behaviors. Objects are specified by definitions, called classes, that specify the attributes and behaviors of the particular objects, which are termed “instantiations” of the class definitions. The reference Budd, T., “An Introduction to Object-Oriented Programming,” Addison-Wesley Publishing Co., Inc. 1991, provides an introduction to object-oriented concepts and terminology.
Object-oriented programming languages make it easier for system programmers to implement the Graphical User Interface (GUI) concepts of icons and lists. For example, if the GUI icons are represented as object-oriented programming objects, the GUI program can be written so that the status of the icon is continuously updated. In this way, it is relatively simple for the GUI program to be written so that the icons can be selected with the graphical user input device and moved about on the computer system display as desired.
With the advent of object-oriented languages also came object-oriented development environments. Such development environments are computer programs or groups of computer programs that allow a software developer to create object-oriented programs. Object-oriented development environments typically have a palette of objects with which the developer builds an application. Each object on this palette is different and serves as a template for the developer. A palette object's attribute settings are the default settings for that object. To use an object on the palette, the developer copies the object and places the copy on the application. The copied or “derived” object has the same attribute settings as the original palette object. These development environments also permit the developer to modify an object and save it as another palette object or create an entirely new object.
Efforts have been made to establish a common method of communication between objects instantiated within a given operating system environment. For example, Microsoft Corporation has established a protocol, known as the Component Object Model (COM), which governs the interaction between software objects within the Microsoft Windows operating environment. COM provides a standard framework which penn its objects from different applications to share data and functions. COM also permits a given application program (“container application”) to contain multiple objects of different types. A format for control objects known as “ActiveX” has been established to take advantage of the COM protocol. An ActiveX object behaves as a “server” relative to its container application, which in turn behaves as a “client.” The COM protocol manages, among other things, the setup and initialization necessary for container applications to send and receive messages and data to and from server applications.
In the context of an ActiveX control, stored data members are known as “properties,” functions are referred to as “methods,” and event occurrences are denoted as “events.” Properties can be read from, and written to, an ActiveX control via associated methods. The interface of an ActiveX control is a set of methods defining certain input, output and behavior rules. Accordingly, a container application can invoke the methods. of an ActiveX control to effect the defined behavior and access the object data.
In addition to representing data stored by an ActiveX control, properties are used in formatting the display of an ActiveX control. Events are utilized to notify a container application of the occurrence of an event, as well as to pass parameters relevant to the particular event. For example, an ActiveX control is capable of informing its container application of the occurrence of a selection event (e.g., when the user interface of the control has been “clicked on”).
ActiveX objects are typically implemented either as in-process servers where the ActiveX control is implemented as a Dynamic Link Library (DLL), or as out-of-process servers as an “executable.” ActiveX DLLs are loaded into the process space of the container application. As a consequence, data does not need to be transported between the container application and the ActiveX control. In contrast, ActiveX executables are loaded into a separate process space from the container application. Since there is no shared memory between such applications, data is transported between ActiveX objects and the container application. This is advantageous in the sense that an ActiveX executable does not interfere with the processing of data in the client application.
Although a number of programming environments exist for facilitating development of ActiveX controls as object-oriented constructs, each such ActiveX control operates independently of the container application. That is, ActiveX controls are conventionally installed in container applications so as not to be affected by changes in parameters of the container application, and vice versa. Similarly, the occurrence of ActiveX events does not automatically cause the execution of scripts or the like in the container application.
Early remote control systems were designed to access and take over the local computer system and run them from a remote location, eliminating any other access and remote operation, as noted in Hyatt (U.S. Pat. No. 5,307,403) and Zapolin (U.S. Pat. No. 5,122,948).
Existing systems as typified by Slaughter (U.S. Pat. No. 5,598,536) permit accessing of data from a local controller system, for example, and the collection of data from the local controller data memory, such as, sensor and other data, as well as the sending of instructions to the controller to set or control certain switches.
Still other systems, as typified by Crater (U.S. Pat. No. 5,805,442), provide for the existence of controller-based web pages which are sent over the Internet and viewed in a browser which accesses the controller as a node on the Web.
Other systems as typified by the Mercury Project papers entitled “Desktop Teleoperation via the World Wide Web”, and “Beyond the Web: Excavating the Real World Via Mosaic” which are attached hereto and incorporated herein by reference, show multiple servers which collect data, configure web pages and provide security features for communication and the exchange of control systems data with multiple clients on the Web.
Each of these systems uses the application running on the local system for control of the local control systems. The browser systems utilize the browser simply as a data input and display device which exchanges data and instructions with the local system.